[syslinux] git repo: primary/secondary/unofficial

[Ady]

> On Sun, Jun 14, 2015 at 4:33 PM, Geert Stappers via Syslinux
> <syslinux at zytor.com> wrote:
> > On Sat, Jun 13, 2015 at 10:44:11PM +0300, Ady via Syslinux wrote:
> >>
> >> > I'm starting this thread to discuss what git repository should be
> >> > designated as primary and which repositories should be designated as
> >> > secondary.
> >> >
> >> > For years, git.kernel.org has been the primary repo, updated at least
> >> > with every full and pre- release.  git.zytor.com has been the
> >> > secondary and development repo.
> >> >
> >> > Additionally, I've maintained my repos at github.com and git.zytor.com
> >> > as unofficial repos with the master branch on each following the
> >> > official repos which I expect to stay this way.
> >> >
> >> > --
> >> > -Gene
> >>
> >> I don't know about primary / secondary / unofficial, but I would like
> >> to mention some points for consideration.
> >>
> >> 1_ repo.or.cz currently uses a web interface similar to the
> >> gitweb-caching interface that was used in git.zytor.com until 2014Oct.
> >> This might not be very important for developers, but it might be
> >> relevant for others (myself included).
> >>
> >> 2_ repo.or.cz is already being used by NASM, and by some contributors.
> 
> This is the reason I'd consider this the best candidate as the new primary.
> 
> >> 3_ github.com has the possibility of "wiki" and "issues". This sounds
> >> as a potential advantage, but it might be a burden. There are not
> >> enough resources (time, developers, contributors...) to maintain yet
> >> another contact channel. Moreover, having multiple channels for the
> >> same objective (bugs, wiki, tracking patches, optionally "linking"
> >> between them...) is probably not such a good idea.
> 
> The github.com issues should only be considered as a replacement to
> the existing bugzilla, not as an additional means of tracking issues.
 
IMHO, the github "issues" tends to be more a "con" than a "pro". Users 
either don't use it, or abuse it.

The current bugzilla has not been used to track bugs effectively, nor 
to track pending patches, or known issues. The problem has not been 
bugzilla itself, but rather the lack of time (by developer(s)) to use 
it effectively. Replacing the current bugzilla with anything else will 
not improve such situation.
 
> 
> >> 4_ The current bugzilla for Syslinux is not very well maintained.
> >> Should a different method / site be considered _instead_ of it? Should
> >> an _additional_ method / site be considered as optional alternative?
> 
> Qualify "not very well maintained".  Is it just the overall attention
> towards issues that varies by everyone's availability?  If so, I think
> you might mean to use other words.
> 
 
The lack of enough available time in the hands of developers (for 
whichever valid reasons), and/or enough (active) contributors, is part 
of the issue.

_ Currently bugzilla.syslinux.org has no "6.03" for the "version" 
field.

_ Anyone changes any field, anything can be considered high priority, 
critically important and urgent, and even those without the required 
knowledge / understanding can set these values as they wish.

_ In some cases bugzilla is being (wrongly) used to ask for help, or 
without being certain that a (potential) bug is present. A hunch, or 
something that is not working as the user expects, is not necessarily a 
matter for bugzilla.

_ During a (long) period of time, emails from bugzilla were not being 
distributed. A user reported a bug, a reply was added, and the original 
reporter had no idea that additional information was requested. Whether 
this situation still continues, I'm not sure.

_ If a valid patch is reported (in bugzilla or in the mailing list), 
nothing happens. Patches are not even acknowledge, nor rejected, nor 
accepted, nor reviewed, nor tracked... for months (and even years in 
some cases). IMHO, this is the most important factor in attracting (and 
keeping) additional contributors.

All these points require some kind of maintenance (thus, time).

I really don't want to sound pessimistic, or to complain without 
generating some positive consequence. Most probably there are valid 
reasons for the lack of resources available to The Syslinux Project.

Tracking pending patches, known issues, feature requests... could be 
"maintained" even in the official wiki (I'm not actually recommending 
it, but it is there if we would want to). Adding contact channels (e.g. 
github.com's "issues", or the current bugzilla, or anything else) 
without having the resources to maintain them (and to reply to users' 
inquiries and improve accordingly) would be counterproductive.
 
> >> 5_ github.com is popular. Would having a github repo attract additional
> >> valuable developers (with the adequate skills)? Or would it result in
> >> more maintenance than it would be worth?
> >
> > Popular should not be a reason to choose.
 
I already replied to this in another email.
 
> >
> >
> >> 6_ I would tend to think that the current 2 official repositories
> >> should be kept (in addition to whatever results from this discussion
> >> and efforts), not replaced.
> 
> Agreed.
> 
> >> 7_ There are other prospects in existence.
> >>
> >> 8_ For any of the potential prospects, actions should be taken so "The
> >> Syslinux Project" could acquire official ownership / privileges /
> >> permissions.
> 
> At the moment, my thoughts are simple:
> 
> 1) Add at _least_ one more official pushable repo.  I'd consider
> adding repo.or.cz, github.com and gitlab.com (gitorious.org is being
> acquired by gitlab.com and being shutdown) as official repos.  Adding
> permissions to any of these should be relatively easy.
> 
> 2) Change the primary repo from git.kernel.org.  Depending on hpa's
> thoughts on the matter, I'd lean towards not using git.zytor.com as
> the primary either.  repo.or.cz is probably the best candidate.
> 
> -- 
> -Gene
 
I would rather see one additional repo added first, without changing 
too much the current status of the current ones. Let's see how it goes 
(More contributors attracted? Faster development pace?). If the effects 
are positive, then additional changes can be evaluated.

In any case, (FWIW) I am not a fan of automatic syncing and/or 
dependency on one exclusive repository.

Regards,
Ady.