[systemd-devel] [ANNOUNCE] Git development moved to github

["Jóhann B. Guðmundsson"]

On 06/09/2015 07:50 PM, Lennart Poettering wrote:
> On Tue, 09.06.15 11:30, Jóhann B. Guðmundsson (johannbg at gmail.com) wrote:
>
>> I would like to see us move and migrated the bugs to jira ( which is without
>> doubt the best and friendliest bug tracker I have found ) which integrates
>> nicely with github as well as move the community wiki to confluence to
>> strengthen collaboration in the community.
> Well, I already feel uncomfortable with moving things to one closed
> source platform in github, but given the advantages I accept
> it. However, moving things to *two* closed source platforms sounds
> even worse to me. If we bind our project to closed source companies I
> much prefer sticking to one, instead of two.

There is no difference between one or many "closed source" since you 
decided to head down this road et all and I have yet to see the problem 
you sought out to alleviate will be solved with that change or that 
change alone for that matter.

Personally I'm not foreseeing us ever hacking on Atlassian source code 
directly but rather extend it via plugins ( locally written or otherwise 
) if the need arise ( which afaik would be only needed for QA related 
stuff ) so I dont see how you really can call this "closed source" 
however the source code for Atlassian products is available to license 
holders and they offer free licenses for official open source projects  
[¹] which covers all the plugins on the market place as well.


>
> Also, while I see quite a few shortcomings in github model, pure bug
> tracking certainly isn't where the shortcomings are, it's more about
> tracking patches where I am not convinced, but I doubt JIRA will fix
> that part for us... or will it?

I beg the differ for pure bug tracking it is quite limited.

The fact is we are long overdue building a proper infrastructure to 
sustain the building block of modern OS.

We need to do proper QA to properly support and backup our downstream 
consumers ( distributions, embedded and otherwise)  and that means 
tagging bugs by distributions, vendors, releases.
Once bug has been validated, write test cases to prevent them from 
happening again. provide them with prebuild packages to test ( and or 
only provide it as btrfs snapshots to avoid having to deal with plethora 
of packaging formats ) write proper release notes, provide proper 
documentation etc. means to correctly identify and allocate resources as 
needed.

The better work we do here is, the less is the work downstream consumers 
have do to downstream.
>
>> I would be the one that would overseeing and handling the migration and I
>> was hoping David Strauss might be willing to host that infrastructure for us
>> and or some other place for that matter ( mini pc in systemd's HQ in German
>> maybe ?)
> I am very much of the opinion that we should be very careful when
> commiting to maintain our own infrastructure. You know how
> undermaintained fdo was, and if we do it on our own it's even
> worse. Administrating our own servers is a huge amount of work
> especially given you have to do this over a long long time
> continously, and our workforce is already too limited for the amount
> of work we have to do.

This is not as high maintenance as you let it out to be or resource 
intensive for that matter.  ( I design this with mini pc in mind, intel 
nuc and the like so this could be hosted here at home if necessary and 
or relocated to Germany if requested )

The infrastructure for this is well maintainable by a single individual 
in his spare time however four ( or more ) individuals providing their 
free time would be optimal.

Your workforce is limited to what you make it out to be and you seemed 
to be fixating on development resources alone which arguably is wrong on 
two accounts.

First development resource are small ( but important ) part of a 
successful project.

Secondly the success to systemd is thanks to collaborated effort between 
individuals residing in downstream consumer community's and this is 
where that collaboration effort would continue to grow since this is 
where the contributed time is best spent ( and least time I checked the 
community was far greater then what ca 20 committed developers  )

That said I was designing my work to reduce work on direct development 
resources not increase it ( which infrastructure resources are supposed 
to do ) so if you have to spent 10 minutes more once implemented than 
you did before this effort will have become a failure..

>
> One of the major benefits of github I think is that it's their very
> business to administer the site for us, and they'll do it as well as
> they possibly can. That gets substantially more difficult if we roll
> that all on our own, given that most of us have little desire to
> become administrators oursevles and we have no budget for paying one
> over years.

I had already taken money issue into account ( and even built a project 
within jira to handle that process ) since I did not expect nor want Red 
Hat to fund this effort.
( The solution to this problem needs to arise from within the community 
to become self sustainable and accepted by all invested parties, there 
is far to red label associated with our collaborated effort )

There are several ways to fund communities, we could offer consultation, 
migration, integration and or forward that work to third party for % of 
the fee he charges and or "sponsor ship ( EU, companies etc 
)",indigo/kickstart campaign ( that helped the Gnome community ) etc.

Btw this is not a replacement to github but addon hence worst case 
scenario we just end up using github just as we started out with.

JBG

1. offer free licenses for official Open Source Projects and community 
organizations