Apologies for quoting out of order. >On 01/14/2014 10:31 PM, Barry Warsaw wrote: >>, but I still think it's not a good idea >> to have some team packages in git and the bulk in svn. I value the >> ability to use the same tools and workflows for all team maintained >> packages. On Jan 22, 2014, at 11:51 AM, Thomas Goirand wrote: >Now, this could be back on the table: it's been months that we've talked >about it, and nothing is happening, because nobody has time. So the only >way I see to switch is to do it slowly, having both SVN and Git for some >time. Other teams have reported that it worked for them, so I don't see >why it wouldn't for python modules. Do you really think that it's unfeasible for git proponents on this team to find the necessary resources to plan an orderly en mass transition? It might indeed be so, we're all busy. But let's hopefully all agree that the end goal is to have all team-maintained packages in the same vcs. So let's say we have to move packages slowly. I want to make sure there's a team commitment (and especially from the git proponents) that we'll have a deadline at which all remaining packages will be switched. I *really* want to avoid the typical long tail where packages just linger under svn and bit rot. (E.g. long tail conversions to dh_python2.) So I would be in favor of an experiment. Pick 5 packages that are representative of team packages, that can be updated and uploaded by anyone on the team, and that see regular but not too often new upstream releases. I'd happily volunteer one of my packages if that helps. Now, conduct an experiment. Convert those 5 packages to git + gbp and do some uploads. Let anyone on the team make changes just as they would in svn. Ask for reviewers. Ask for sponsors. The most important thing though is to *document* in detail *on the wiki* how to work with those packages in git. Be opinionated, like the way we are with the LibraryStyleGuide. Don't worry if others disagree with you - we can hash out best practices in this mailing list over time, but it's really important to put a stake in the ground. If you can't decide which of two ways is better, do one package one way and another the other way. It's not good enough if the only instructions that exist are in mailing list archives. I don't want to force team members who come after us to have to excavate through countless emails to find out the way we want things done. On Jan 22, 2014, at 11:51 AM, Thomas Goirand wrote: >Yes, because someone found it useful to disable the git area in the team >repo on Alioth [1] !!! And this drove people to collab-maint. This was >predictable, predicted, and unavoidable. I don't know if my proposed experiment means re-enabling git on the team repo or doing the experiment on collab-maint. Obviously, like the long tail of svn above, I want the end result to eventually be all the packages back in the same place, but for now, if collab-maint is good enough for this experiment, then that would be fine. >It all depends how you do it. If you base your Git packaging on tags, >and not using branches, which means having a debian/gbp.conf that >configures this, then it's really strait forward. I know there will be many different ways to do it, just like today there are many different ways to write your packaging. Don't try to cover every possibility. That can come over time. Tell me what *you* think are the best ways to do it that will cover 80% of the packages we collectively maintain. We can deal with outliers, options, and alternatives later. >On 01/14/2014 11:51 PM, Olivier Berger wrote: >> It more or less requires only 2 branches : upstream (when you >> want to track upstream sources) and master (or debian) for the >> packaging source. > >Hum... I'd say that *your workflow* requires it, but git-buildpackage >itself doesn't. You don't have to do this way. Everything can be >contained in a single branch if you use tags. Also, if you don't use >tags, and prefer to use upstream tarballs, then I think you're much >better off using pristine tar (and git-import-orig). I don't really have a good sense of what's better. Upstream tarballs + pristine tar seems more comfortable coming from the svn way, but tags and or branches seems more like Ubuntu Distributed Development, which I very much like despite the problems[*]. So I don't know, pick what you like and tell me how to do it. Is that doable and worthwhile? Cheers, -Barry [*] which include: - branch importer failures causing branches to be out of sync with the archive - sort of working integration with quilt, but still kind of crappy in general - not as awesome in practice as it *could* be - choice of dvcs But then my question is: how closely does your vision of the team git repo overlap with general Debian initiatives like dgit and source branches? It might be nice if they align rather closely.
Attachment:
signature.asc
Description: PGP signature