[Dev] Request-4-Opinion: marking deactivated git repos

Carsten Haitzler c.haitzler at samsung.com
Thu Dec 29 05:22:52 GMT 2016


On Thu, 29 Dec 2016 05:13:53 +0000
MyungJoo Ham <myungjoo.ham at samsung.com> wrote:

> >On Thu, 29 Dec 2016 04:51:03 +0000
> >MyungJoo Ham <myungjoo.ham at samsung.com> wrote:
> >  
> >> > On Thu, 29 Dec 2016 04:29:28 +0000
> >> > MyungJoo Ham <myungjoo.ham at samsung.com> wrote:
> >> > 
> >> > what we do in enlightenment upstream is we literally rename
> >> > "dead" repositories. we also mark them clearly in description:
> >> > 
> >> > https://git.enlightenment.org/
> >> > 
> >> > look at "Legacy". we do this so code is available if someone
> >> > wants to dig through it, but it:
> >> > 
> >> > 1. is clear by description and/or PATH to git repo that its
> >> > legacy (old/dead).
> >> > 2. it will force good old build scripts to break - thus informing
> >> > whoever runs such tools by way of their build breaking that
> >> > things have moved/changed.
> >> > 
> >> > so i agree that it'd be good to rename and change descriptions
> >> > when a repository is abandoned. we should reduce the number of
> >> > repos perhaps in the process.    
> >> 
> >> Renaming may incur problems with build processes targetting old
> >> Tizen versions.
> >> 
> >> I wish we've never renamed any active git repositories; but we've
> >> already committed such sins. Therefore, there are a lot of git
> >> repos that are used by some build projects while not supposed to
> >> get any attention from code writers.
> >> 
> >> Thus, renaming (or moving) git repos might need some aliasing
> >> (e.g., symbolic links) so that developers might be able to
> >> distinguish them quickly while obsolete build systems (for
> >> obsolete projects) may keep access them.  
> >
> >if the code is no longer maintained, worked on, patched, fixed etc...
> >shouldn't it break old builds? shouldn't the people doing the build
> >know that this is now an orphaned repository and no one is going to
> >look after it?  
> 
> For example, can you identify whether it's deactivated or not by
> simply looking at it? (it's dead now.)
> https://review.tizen.org/gerrit/gitweb?p=apps/core/preloaded/quickpanel.git;a=summary
> 
> If app/core/preloaded/quickpanel is renamed as
> DEAD/app/corea/preloaded/quickpanel, I'm happy with it.
> 
> However, the build systems that tries to get Tizen 3.0 or 2.x will be
> broken. That's what I'm concerned with simply renaming/moving dead
> packages. (And that's why I though aliasing/symlinks for them might
> be needed)
> 
> And, I do not want to break old (at least for 3.0) builds. (not
> personal builds, but the builds at build.tizen.org).

ok. well tizen 3 isn't old.. :) i was thinking tizen 2.0 or 1.0 ...

there is also a description that gerrit lists next to the repo when
you list repositories. that description could begin with "LEGACY |" or
"MOVEDTO xxxx |" or "DEAD |" so a quick look at the repo in gerrit would
tell you what you need.

also perhaps add a "DEAD.txt" file in the base of the git repo would
be a clear sign. it could contain information as to what to do (move to
a new repo url, never use this software again as it's obsolete etc.).

if the code in the repo is REALLY dead and going to be ignored from now
on... a move is a good idea. :) if we're just talking about tizen 3
then that's far from legacy at this point :)


More information about the Dev mailing list